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Verification of Control Systems Implemented in 
Simulink with Assertion Checks and Theorem 
Proving: A Case Study 

Dejanira Araiza-Illan* Kerstin Ederj and Arthur Richards^ 


Abstract 

This paper presents the verification of control systems implemented in 
Simulink. The goal is to ensure that high-level requirements on control 
performance, like stability, are satisfied by the Simulink diagram. A two 
stage process is proposed. First, the high-level requirements are decom¬ 
posed into specific parametrized sub-requirements and implemented as 
assertions in Simulink. Second, the verification takes place. On one hand, 
the sub-requirements are verified through assertion checks in simulation. 
On the other hand, according to their scope, some of the sub-requirements 
are verified through assertion checks in simulation, and others via auto¬ 
matic theorem proving over an ideal mathematical model of the diagram. 
We compare performing only assertion checks against the use of theo¬ 
rem proving, to highlight the advantages of the latter. Theorem proving 
performs verification by computing a mathematical proof symbolically, 
covering the entire state space of the variables. An automatic translation 
tool from Simulink to the language of the theorem proving tool Why3 is 
also presented. The paper demonstrates our approach by verifying the 
stability of a simple discrete linear system. 


1 Introduction 


The implementation of control systems before deployment needs to be verified, 
particularly in domains that involve safety-critical systems 17 . The design of 


a control system is typically followed by numerical simulation before its final 
realization as code. Increasingly, automatic code generation is employed to 
generate real-time deployment code from the simulation [11| , reducing the risk 
of errors in hand-coding. In this paper, we propose a method for verifying that 
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the simulation, embodied in a Simulink diagram, satisfies the requirements of the 
original system. This method seeks to identify and eliminate errors introduced 
during the control design in the simulation stage. 

Testing and formal methods, namely model checking and theorem proving, 
have been used to verify systems at different design or implementation levels. 
None of them are adequate to cover all stages at once in practice. A particular 
challenge in verifying a control system is the presence of signals and parame¬ 
ters in the domain of the real numbers, which leads to an infinite number of 
states and state-space explosion problems for some of the verification methods. 
In testing, samples of the state space of the variables and parameters are used 
when executing a model of the system, helped by automated search methods as 
in [7 24 25 for Simulink diagrams. Model checking is the exhaustive traversal 
of a model of a system (i.e., enumerating all the states in the model) to check 
for properties [^. Model checking requires a discrete or hybrid state model of 
the system; it can be affected by the state-space explosion problem. Theorem 
proving, also denominated deductive verification [10| , comprises a family of tools 
to find a mathematical proof of a requirement, automatically via Satisfiability 
Modulo Theory (SMT) solvers or Satisfiability (SAT) solvers, or interactively 
(i.e., with additional user guidance). Theorem proving allows generalizing over 
the entire state-space, as verification problems are posed symbolically. Different 
kinds of requirements of Simulink diagrams have been verified through model 
checking [4||9 17 20 27 and theorem proving [^|^|^|^[^. The stability of 


systems and controllers described mathematically has been verified in theorem 
provers 12p8 , but the translation from a mathematical form into the input lan¬ 
guages is performed manually. Other approaches verify stability of controllers 
implemented as C code 14,26 , instead of at a design level. Many of the theo¬ 
rem proving approaches for Simulink make use of interactive tools il 


whereas fewer use the automation provided by SMT or SAT solvers BeI] 

In this paper, we present the verification of Simulink diagrams of control sys¬ 
tems with respect to high-level design requirements like stability. Our approach 
involves two stages. First, the high-level requirements are decomposed according 
to control theory into specific parametrized sub-requirements and implemented 
as assertions in Simulink. Second, the property is verified. We compare two 
verification methods to highlight the advantages of theorem proving over sim¬ 
ple assertion checks. First, we perform simple assertion checks in simulation. 
Secondly, we divide the sub-requirements into assertion checks, if they corre¬ 
spond to numerical computations of the constants, and into proof goals to be 
translated for verification via automatic theorem proving with SMT solvers, if 
they include system variables. This latter separation into assertion checks and 
theorem proving was chosen due to the practicality of performing numerical 
computations in MATLAB instead of SMT solvers, otherwise our intention is 
to use theorem proving. A large number of assertion checks in simulation would 
verify a great part of the system’s state space against the requirements, but this 
coverage is not complete. Furthermore, a large number of checks would consume 
time and memory. A mathematical proof obtained from the verification via the¬ 
orem proving is symbolic (i.e., for all the possible values of any variable), and 
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an answer can be computed within a reasonable amount of time and memory 
resources if using SMT solvers. 

Our paper proposes automated translation of SimulinlQ into a language for 
theorem proving, to reduce errors introduced by manual translation. In partic¬ 
ular, we translate the Simulink model into Why, the logic language of the Why3 
tool [^. This tool translates Why code into the input language of SMT solvers 
and allows interfacing with them directly, to compute mathematical proofs au¬ 
tomatically. In the translation, the Simulink diagram’s blocks are captured as 
relations of their input and output signals. Assertions become verihcation goals. 
We provide Why libraries containing mathematical definitions for some blocks 
and their properties, to facilitate the translation process. 

This paper demonstrates our verification approach by means of a case study, 
verifying stability of a discrete linear feedback system. Our initial results pave 
the way for more ambitious challenges related to the verification of autonomous 
systems, such as a model predictive controller (MFC). 


2 Case Study Description and Requirement 


Consider a linear discrete system in state-space equation form 

x(fc -I- I) = Ax(fc) -|- Bu(fc), 


( 1 ) 


with the specific values 

r -1.50 -0.50 ■ 

^ “ [ -0.50 -1.00 J ’ 

This system is unstable. We need to design a feedback controller for the system 
in Q to satisfy the requirement: the closed-loop system shall be stable. 
A controller is proposed. 


2.00 

- 1.00 


( 2 ) 


u(fc) = -Kx(fc), K = [ -2.01 -1.32 


( 3 ) 


which has been found by pole placement 13 , with desired poles of [0.8, —0.6]. 


The implementation of this system and controller in Simulink is shown in the 
top section of Fig. The constants defining the system and controller are 
explicitly added as Constant blocks, to be treated symbolically in mathematical 
proofs. 


3 Verification Process 

Lyapunov’s second method has been applied directly to determine the stability 
of the implemented system. A candidate Lyapunov function is the following: 

F(x(/c)) = x(/c)'^Px(fc), (4) 

^Available from: https://github.com/riveras/simulink 
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Table 1: Requirements Decomposition 


ID 

REQUIREMENT 

VERIFICATION 

METHOD 

Rl 

The closed-loop system shall be stable. 

Decomposed: Rl.l and 
R1.2 

Rl.l 

The function V(x(fc)) shall be positive so long 
as x{/c) 7^ 0. 

Decomposed Rl.1.1 

Rl.1.1 

The matrix P shall be positive definite. 

Simulink check 

R1.2 

The function V(x(fc)) shall be strictly decreas¬ 
ing when x(Ai) 7^ 0. 

Decomposed: Rl.2.1 

and Rl.2.2 

Rl.2.1 

The decrease of the function V{x{k)) 
shall be equal to x(/c)'^[P — 

(A - BK)'^P(A - BK)]x(fc). 

Theorem prover 

Rl.2.2 

The matrix P - (A - BK)'^ P{A - BK) shall 

be positive definite. 

Simulink check 


where 

_ r 22.01 16.93 ■ 

^ “ [ 16.93 15.16 J ’ 

calculated by solving the discrete Lyapunov equation 

(A - BK)^P(A - BK) - P = -I 

With this information, the requirement can be decomposed as illustrated 
in Table The high-level stability requirement (Rl) is decomposed into two 
child requirements, showing that P(x(fc)) is a Lyapunov function for the closed- 
loop system. Sub-requirement Rl.l corresponds to the property of positivity 
of a Lyapunov function. This sub-requirement can be proved based only on the 
positive dehniteness of the constant matrix P (Rl.1.1). The requirement for 
decreasing V{x{k)) (R1.2) is decomposed into two child requirements: Rl.2.2, 
another property of positive dehniteness based on constants; and Rl.2.1 an 
identity check of the Lyapunov discrete equation and the Lyapunov’s function 
difference (i.e., the right Lyapunov equation was used to compute matrix P). 
The latter is more suited to be verihed through mathematical proof via theo¬ 
rem proving as, besides avoiding boating point issues, it refers to a comparison 
of the functionality of sequences of blocks in the Simulink diagram, and it in¬ 
volves system variables with an ample range of values. The SMT solvers, via 
Why3, would analyze the mathematical description of the Simulink diagram’s 
structure, to hnd a proof of the identity or not. Verifying all sub-requirements 
Rl.1.1, Rl.2.1 and Rl.2.2 would verify the stability requirement. We verify 
the positive dehniteness sub-requirements numerically in Simulink by requiring 
the minimum eigenvalue to be positive. 

The requirements in the lowest level of the decomposition (e.g., Rl.1.1, 
Rl.2.1 and Rl.2.2) can now be added to the Simulink diagram, attached to 
Numerical Or Goal blocks, which have Assert blocks inside. Upper level require¬ 
ments (e.g., Rl.l and R1.2) can be incorporated into the Simulink diagram to 
add conhdence, even though they are verihed by their sub-requirements. The 


( 5 ) 

( 6 ) 
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Figure 1: Added Requirements into the Simulink Diagram. System Blocks in 
Gray. E1-E7: Locations of Introduced Errors. 


requirements that are connected to Numerical blocks are verified only through 
assertion checks in simulation. They should only depend on constants, such 
that they are proven to always hold. This constraint can be enforced through 
adding static analysis of the Simulink diagram. Goal blocks also contain Assert 
blocks and can be checked in simulation. Goal blocks are used as indicators 
for the translation, being formatted to be verified, whereas Numerical blocks are 
ignored. The remaining blocks in a Simulink diagram are also translated. 

The use of numerical methods to compute the eigenvalues for positive deh- 
niteness, and any other computation in simulation, are subject to errors due to 
the use of floating point. For this reason, the identity comparison was encoded 
as an approximation; \vi — F 2 I < e, where e is an error bound (e.g., 1 x 10“®). 
The implications of floating point computations with respect to the satisfaction 
of the high-level requirements can be investigated in a further analysis level, as 
in for fixed-point of code implementations of Simulink diagrams. 

The number of basic blocks added to the original implementation for the 
verification is quite signihcant, as shown in Fig. This trade-off of adding 
components to perform the verification is well known in the hardware domain. 
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where test-bench code can amount to 80% of the code in a simulation . 


4 Translation Process 


The Simulink diagram is translated automatically to Why, the language of 
Why3 , to symbolically verify sub-requirements with theorem proving. Why3 
automatically translates Why code into the input language of SMT solvers, and 
controls them directly. The automation of the translation reduces the amount 
of manual input, and consequently the possibility of introducing errors. The 
translation procedure has been implemented as a script in MATLAB. The script 
converts a diagram into an abstract syntax tree 2][^ and other data structures, 
and then follows them when writing the Why code. The translation preserves 
the semantics. 

In the translation, a logical description of the system’s mathematically ideal 
functionality and properties is represented as a theory. This Why file is provided 
to Why3, and the requested SMT solvers will try to compute a proof of the 
satishability of the verihcation goals with respect to this system’s description. 
A theory is formed by the signals connecting the blocks, a logic description of 
the functionality of each block, and the proof goals (assertions from the Goal 
blocks). 

Input and output block signals are represented as discrete time functions, 
mapping an integer to a matrix, in a curried convention. In this paper, we 
translate all the signals as matrices, an abstraction of vectors and scalars. The 
signals are named after the block they originated from: 


1 function b_block_name int : matrix 


The functionality of each block is added by “cloning” (or statically linking) a 
predehned block’s mathematical definition (also in a theory form), parametrized 
by the input and output signal names. The definition in Why for a particular 
block is chosen according to the Block Type or MaskType. Why definitions (theo¬ 
ries) for a set of basic blocks have been developed and are used internally by 
the translator. The definitions describe the relation between a block’s inputs 
and outputs. For example, the Sum block was defined as: 


2 

3 

4 

5 

6 

7 


theory Sum.Add 


use import matrix 

Matrix 

function ini int : 

matrix 

function in2 int : 

matrix 

function outl int 

matrix 

axiom def : forall 
k) (in2 k) 

end 

k: int . outl k = m_sum (ini 


The produced theory in Why for the system in this paper has the structure: 
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Figure 2: Controlled System’s State Variables x{k). 


theory System .controller 
use import matrix. Matrix 
function b_a int : matrix 

clone Sum_Add as B.x.next with function ini = 
b.ax , function in2 = b.bu , function outl = 
b _x.next 

goal G-b.compare : forall k;int. v.diff k = 
vdiff.an k 

end 


We dealt with the presence of subsystems by translating them as individual 
theories. Otherwise, they can be masked and considered as basic blocks, with 
their respective definitions added to the library for the translator. 

Additionally, we have developed a linear algebra theory in Why, containing 
our definitions of matrix, algebraic operations and properties (e.g., commuta¬ 
tivity, associativity), based on other linear algebra theories [^[W,22 . Our 


definitions are based on real numbers, corresponding to an ideal mathematical 
model of the system in the Simulink diagram. For example, matrix multiplica¬ 
tion, and an associativity of matrix multiplication axioms are defined as: 


1 function mxm matrix matrix : matrix 

2 axiom assoc.mult: forall ml m2 m3: matrix. 

3 mxm (mxm ml m2) m3 = mxm ml (mxm m2 m3) 


5 Evaluation and Results 

The correct Simulink diagram of the designed control system yields a stable 
behaviour and convergence of the state to an equilibrium point in the origin, 
as shown in Fig.[^ We compared performing verification with simple assertion 
checks in simulation at different sub-requirement decomposition levels, against 
verifying based on a separation of assertions about constant parameters and 
assertions about variables tackled through symbolic mathematical proof via 
theorem proving. This comparison allows commenting on the importance of 
a more comprehensive methodology for the verification of a Simulink diagram. 


7 



























and showcases the advantages of our use of theorem proving to automatically 
verify some of the sub-requirements, for the entire state-space of the variables. 

Errors have been injected into the Simulink’s components of the system or 
verification, as identified in Fig. 

El. The feedback is reversed by using an Add block instead of Subtract for x_- 
next, leading to A -|- BK and making the system unstable. P and K are 
computed for A — BK. 

E2. K is computed for A + BK but we implement A — BK. This error can 
happen when loading — K into the workspace by mistake. 

E3. Using a positive definite matrix P computed with (A — BK)"”" and not 
A — BK. This error is likely to happen as MATLAB’s diyap function 
requires the transposition of the system’s parameters. 

E4. Inversion of the difference V (x(fc)) — V (x(fc— 1)) to V (x(fc— 1)) — V (x(fc)). 
This is achieved by swapping the inputs to the corresponding Subtract 
block. 

E5. Swapping a Subtract block for an Add block when computing the predicted 
Lyapunov function change. This means assuming positive feedback in¬ 
stead of negative feedback. 

E6. Inverting the sign in the predicted difference of the Lyapunov function 
by swapping the inputs of the corresponding Subtract block, resulting in 
P - (A - BK)'^P(A - BK) instead of (A - BK)^P(A - BK) - P. 

E7. Extra Gain block in the system, such that x{k -I- 1) = 0.8(A — BK)x(fc) is 
a stable system but different to the one used for design. 

The first two errors are used to illustrate the results of the verification ap¬ 
proach when the system is unstable and a Lyapunov function is proposed. The 
other five errors show that errors in the added assertions do not lead to false 
conclusions about the high-level requirement being verified, stability. 

We used an Intel i5-3230M 2.60 GHz CPU, with 8 GB of RAM, running 
Ubuntu 14.04, and Simulink in MATLAB R2013a. We used the Z3 (version 
4.3.1) and CVC4 (version 1.4) SMT solvers controlled through Why3 
(version 0.81). Why files were produced automatically using the translation of 
Section IH 


Table 2: Evaluation Results 


REQ. 

METHOD 

CORK. 

El 

E2 

E3 

E4 

E5 

E6 

E7 

Checking Assertions for Different Initial Conditions in Upper and Lower Sub-requirement Levels 

Rl.l 

Simulink check: x(0) = [1,1]^ 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Rl.l 

Simulink check: x(0) = [1, —0.8]"^ 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

R1.2 

Simulink check: x(0) = [1,1]^ 

Pass 

FAIL 

FAIL 

FAIL 

FAIL 

Pass 

Pass 

Pass 

R1.2 

Simulink check: x(0) = [1, —C.B]"”" 

Pass 

FAIL 

FAIL 

Pass 

FAIL 

Pass 

Pass 

Pass 

Rl.1.1 

Simulink check (any initial condition) 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Rl.2.1 

Simulink check: x(0) = [1,1]^ 

Pass 

FAIL 

FAIL 

Pass 

FAIL 

FAIL 

FAIL 

FAIL 

Rl.2.1 

Simulink check: x(0) = [1, —0.8]"^ 

Pass 

FAIL 

FAIL 

Pass 

FAIL 

FAIL 

FAIL 

FAIL 

Rl.2.2 

Simulink check (any initial condition) 

Pass 

Pass 

FAIL 

FAIL 

Pass 

FAIL 

FAIL 

Pass 

Division of Sub-requirements in Lowest Level into Assertion Checks and Theorem Proving 

Rl.1.1 

Simulink check 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Rl.2.1 

Theorem proving 

Pass 

FAIL 

Pass 

Pass 

FAIL 

FAIL 

FAIL 

FAIL 

Rl.2.2 

Simulink check 

Pass 

Pass 

FAIL 

FAIL 

Pass 

FAIL 

FAIL 

Pass 




Table [2] shows the verification results. The column labelled cqrr. refers to 
the nominal stable system and a correctly applied Lyapunov’s second method. 
Columns ei-e7 show the verification results for systems with errors. In simu¬ 
lation, a Pass means the assertion passed the check, whereas fail indicates the 
assertion failed the check. In theorem proving. Pass indicates that both SMT 
solvers found the assertion valid, which is expected after less than 10 seconds. 
FAIL indicates the failure to prove the assertion: the SMT solvers timed out after 
100 seconds, or ran out of memory within 100 seconds. 

For the verification based on simple assertion checks, two initial conditions, 
x(0), were applied and simulated for 10 seconds. First, the assertions corre¬ 
sponding to the first decomposition level in Table Rl.l and R1.2, were 
checked. Then, sub-requirements Rl.1.1, Rl.2.1 and Rl.2.2 were checked, 
to highlight the advantages of the decomposition. False positives of the high- 
level stability requirement are likely to emerge for errors E3 and E5-E7, if 
only (Rl.l and R1.2) are checked: the Lyapunov function is positive and de¬ 
creases for the chosen initial conditions, leading the designers to conclude the 
system is stable. This lack of information about the system can be corrected 
through simulations for more initial conditions. Alternatively, the lowest level 
of sub-requirements can be considered instead. Sub-requirements Rl.1.1 and 
Rl.2.2 provide information about the system’s constant parameters that does 
not depend on the system’s variables. Sub-requirement Rl.2.1 provides in¬ 
formation about the coherence of the system’s structure with respect to the 
Lyapunov’s second method. The same false positives are avoided if checking 
sub-requirements Rl.1.1, Rl.2.1 and Rl.2.2 instead, for the same initial con¬ 
ditions. Nevertheless, checking requirement Rl.2.1 numerically in simulation 
is subject to floating point issues. These numerical issues, present in the verifi¬ 
cation of sub-requirements about variables in the system, can be alleviated by 
the use of theorem proving, due to its symbolic nature. 

For the second verification alternative, the verification of sub-requirements 
Rl.1.1, Rl.2.1 and Rl.2.2 is split into assertion checks and mathematical 
proof via theorem proving, as means to verify the high-level requirement if all 
the assertions are verified as valid. For requirements Rl.1.1 and Rl.2.2, we 
considered the results of the previous assertion checks, since they do not depend 
on initial conditions nor simulation time. The results in Table[2]indicate that ev¬ 
ery error is detected, as the verification of at least one the three sub-requirements 
fails. All the error implementations preserved the positive definiteness of the 
matrix P in the candidate Lyapunov function, so requirement Rl.1.1 is sat¬ 
isfied. The analysis of requirement Rl.2.1 by theorem proving fails for errors 
El and E4-E7, where the assertions are not consistent with the system. The 
implementations with errors E2 and E3 are valid according to theorem proving, 
as sub-requirement (Rl.2.1) is verified symbolically (i.e., without considering 
the values of the matrices in the system). Errors E2 and E3 refer to matri¬ 
ces P and K, and the numerical analysis detects them instead. Errors E3-E6 
demonstrate the importance of adding assertions correctly. 

The use of formal methods, in particular theorem proving, allows the ver¬ 
ification of sub-requirements for all possible state-space values and parameter 
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combinations at once, due to their inherent symbolic nature. This is advan¬ 
tageous compared to running a large amount of simulations, which can never 
be exhaustive for systems with variables in the domain of the real (or floating 
point) numbers. Formal methods can be complemented with simulation-based 
testing (i.e., running a comprehensive set of assertion checks in simulation), as it 
can be used to find examples in the state-space that cause the failure of the as¬ 
sertions. Also, simulation-based testing can help to establish if an implemented 
control system fulfils its purpose with a target environment. 

Since the sub-requirements added as assertions in Simulink make use of 
default blocks, other tools for testing and model checking such as Simulink 
Design Verifier 23 can complement the theorem proving verification approach. 
Also, the assertions can be exported as part of automatically generated code, 
to act as monitors at runtime. 


6 Conclusions 

In this paper, we presented an approach to verify high-level properties of control 
systems represented as Simulink diagrams. We use popular implementation 
and verification tools like Simulink and Why3. The approach provides more 
automation in the verification process, through the automatic translation of 
the Simulink diagrams for theorem proving, and the use of automatic theorem 
provers. The approach can be extended to verifying a variety of high-level 
properties for different systems, and can be complemented by other verification 
methods, such as simulation-based testing. The verification of errors in the 
Simulink diagrams presented in this paper illustrates the need for verification 
of control systems designs, before code generation. 

We have exemplified our approach through the stability analysis of a con¬ 
trolled discrete system, using Lyapunov’s second method. We showed how to 
derive sub-requirements from a high-level requirement such as stability. We 
also showed how to add these sub-requirements into the Simulink diagram, using 
Simulink’s default blocks. Although the sub-requirements can be verified in sim¬ 
ulation, using assertion checks in Simulink, a more efficient and comprehensive 
option is separating the verification of the sub-requirements into assertion checks 
(for constant parameters), and automatic theorem proving via SMT solvers (for 
system variables). The Simulink diagram can be automatically translated into 
Why (the logic language of the Why3 tool), to reduce errors from manual in¬ 
put. The use of theorem proving combined with numerical checks about the 
system’s constants, provides a stronger set of assurances about the high-level 
requirements of the system, since theorem proving is symbolic and results in a 
mathematical proof that covers the entire state space of variables. Compara¬ 
tively, assertion checks are not exhaustive over variables or parameter choices, 
but they can be used to complement theorem proving by providing examples of 
the violation of a requirement. 

We want to apply the method and tools to more complex systems in the 
near future, such as an MFC with automatically derived Lyapunov functions. 
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Also, we are expanding the amount of supported Simulink blocks to be used in 
diagrams, and our linear algebra library. 
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